In diesem Interview spricht Dr. Carola Lilienthal darüber, dass es in jeder Organisation viele Gründe und Geschichten gibt, die die Mitarbeiter miteinander erlebt haben und auf die sich ihr Verhalten aufbaut. Diese Geschichten müsse man als Externer verstehen und würdigen, um Veränderungen in Gang setzen zu können.

Erörterung zu Conway’s Law

Melvin E. Conway hat 1968 die Beobachtung angestellt, dass das Design von Systemen Kopien der Kommunikationsstrukturen der Unternehmen darstellen, die diese Systeme entwickeln. Was bedeutet das konkret für Software-Architekten?
Hängen Software-Architekten in ihrer Arbeit davon ab, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist, wie die Mitglieder der einzelnen Team miteinander reden und zusammenarbeiten?

W-JAX: Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt?

Dr. Carola Lilienthal: Bei einem Kunden von uns waren die Teams nach Programmiersprachen geschnitten, so dass ein Team für die C#-Clients, ein Team für die Java-Server-Komponenten und ein Team für das PLSQL in den Datenbanken zuständig war. Diese Aufteilung führte dazu, dass die fachlichen Begriffe in den einzelnen sprachlichen Teilen und auch Teams nicht einheitlich verwendet wurden und so an den Schnittstellen häufig Missverständnisse auftraten. Kunden, die verschiedene Clients benutzten, hatten ein einheitliches Frontend, aber die Abstimmung zwischen den Programmiersprachenteams kostete viel Zeit und führte immer wieder zu Hacks, damit die Teile zusammen passen.

Schließlich hat der Kunde auf Feature-Teams umgestellt, in denen jeweils Team-Mitglieder mit unterschiedlichen Programmiersprachenkenntnissen an einem Feature zusammen arbeiten. In der darauffolgenden Zeit wurde die fachliche Struktur der Software viel klarer. Es wurde allmählich möglich, fachlich geschnittene Microservices mit ihrem eigenen Datenbankschema und ihrem eigenen Client-Code zu separieren. Je länger die Teams so arbeiteten, desto eher kam es nun vor, dass die Oberfläche an Einheitlichkeit verlor. Jedes Team machte seine eigenen Oberflächen unabhängig von den anderen Teams.

Schließlich wurde ein kleines Team eingeführt, das dafür zuständig ist, auf die Einheitlichkeit der Oberfläche zu achten.

Durch Domain-Driven Design wird die Fachlichkeit explizit in den Fokus der Softwareentwicklung gerückt.

W-JAX: Welches Mittel hat sich in deiner Praxis bewährt, um den Effekten von Conway’s Law zu begegnen?

Dr. Carola Lilienthal: Das einzige Mittel, das sich in meiner Praxis bewährt hat, ist, mit Menschen direkt zu sprechen. Wenn ich in ein Unternehmen komme, um Veränderungsprozesse anzustoßen, dann gelingt mir das nur, indem ich zu den Beteiligten gehe und mit ihnen spreche. Für vorhandene Strukturen und Prozesse gibt es in jeder Organisation viele Gründe und Geschichten, die die Mitarbeiter miteinander erlebt haben und auf die sich ihr Verhalten aufbaut. Diese Geschichten muss man als Externer verstehen und würdigen, um Veränderungen in Gang setzen zu können.

W-JAX: Ist Conway’s Law umkehrbar? Hängt gute Architektur also von den Organisationsstrukturen eines Unternehmens ab?

Dr. Carola Lilienthal: Nein, eine gute Softwarearchitektur braucht Softwareentwickler und Softwarearchitekten, die wissen, wie eine gute Softwarearchitektur aufgebaut werden soll, was für Qualitätsanforderungen an eine gute Softwarearchitektur gestellt werden müssen und an welchen Stellen Flexibilität in der Softwarearchitektur vorgesehen werden müssen, damit die Softwarearchitektur langlebig ist. Diese Punkte haben nichts mit der Organisation oder den Kommunikationsstrukturen zu tun.

W-JAX: Jeff Sussna hat einmal in einer Keynote darauf hingewiesen, dass Conway aus seiner Ursprungsthese etwas seiner Meinung nach viel Wichtigeres folgert. Dass es für jedes gegebene Design nämlich immer ein noch besseres geben könnte. Wichtiger als gutes System-Design wird damit die Fähigkeit zum Redesign. Würdest du dem zustimmen? Und wenn ja, wie kann man dem in der Software-Architektur Rechnung tragen?

Dr. Carola Lilienthal: Ich bin mit Jeff Sussna einer Meinung, dass eine Architektur immer so designt werden muss, dass sie änderbar bleibt. Allerdings ist es schwierig, alle möglichen Änderungen vorauszuahnen. Welche Oberflächen-Devices die Zukunft für uns bereithält, ist schwierig im Voraus zu wissen. Grundsätzlich bin ich überzeugt davon, dass die erste Lösung, die man entwickelt, nie die beste ist, weil es nur der erste Versuch ist. Softwareentwicklung ist ein Lernprozess, bei dem das Entwicklungsteam immer neue Erkenntnisse in die Software überführen muss. In Acht nehmen muss sich ein Entwicklungsteam allerdings vor der Versuchung, allein ob der Schönheit des Designs immer weitere Überarbeitungen vorzunehmen. Das wird dann der typische Tot in Schönheit. Redesigns sollten nur aufgrund von falsch verstandener Fachlichkeit und schlecht umgesetzter Qualitätsanforderungen an die Architektur vorgenommen werden.

W-JAX: Welcher Aspekt in der aktuellen Diskussion um Softwarearchitektur ist für dich besonders anregend für deine Arbeit?

Dr. Carola Lilienthal: Neben Conway’s Law hat die Diskussion zu Domain-Driven Design und Microservices meine Arbeit in den letzten Jahren sehr beeinflusst und vorangebracht. Durch Domain-Driven Design wird die Fachlichkeit explizit in den Fokus der Softwareentwicklung gerückt. Microservices bieten dann die technische Umsetzung, um die großen fachlichen Strukturen in Software abzubilden.

Das einzige Mittel, das sich in meiner Praxis bewährt hat, ist, mit Menschen direkt zu sprechen.

W-JAX: Carola, Domain-driven Design ist dein Thema auf der kommenden W-JAX. Welchen Zusammenhang siehst du zwischen DDD und der Theorie Conway’s?

Dr. Carola Lilienthal: Conway gibt die theoretische Fundierung zu der Empfehlung von Eric Evans bei Domain-Driven Design, dass es pro Bounded Context (abgegrenzter Teil der Fachlichkeit) ein eigenes Team geben soll. Ein Bounded Context soll seine Fachlichkeit konsistent unabhängig von den anderen Teilen der Software umsetzen. Dieses Ziel erreicht man laut Eric Evans und auch nach der Theorie von Conway am besten, wenn ein geschlossenes Team an der Software für diesen Bounded Context arbeitet.